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ADVENTURER "8 ANSWERS 


If you don't aind the late night hours and thrive on 
the challenge, then beware! This coluen is not for you! If, 
however, you are ready to give up and can't stand the 
thought of one sore sleepless night, then read on! 


MYSTERY FUNHOUSE 
froa Scott Adaes 
the solution 


A Fun House may be a strange place for espionage, but 
secret agents have a habit of popping up where you least 
expect then. 


You stand, shoes in hand, outside the Fun House. If 
you had some money, you could get inside. The first thing 
to do is drop the watch and go east to the parking lot. 
Ignore the five dollar bill (it's a grocery bill), and look 
at the tree. 


Get the branch, then look in the grate. Chew the que 
(tastes HORRIBLE!), then stick it on the branch. Use the 
branch to get the coin, then drop both the branch and the 
gue. Return to the Fun House entrance. 


Wear the shoes and give the dollar for a ticket. 60 
Fun. You are standing in the Magical Mirror Roos, and just 
up ahead is a fe. 6o north three times, then West twice. 
This brings you to a small room. Go west froe here to the 
rooa with the knobs. Pull the green knob, and you will find 
yourself in another room, Get the traepoline, then go south 
to the shooting gallery and pick up the strange spectacles. 
Ba north, then up, to the knob roos. 


Head along west to the tank room, and from there, up 
to the ledge over the pit. Drop the traspoline, then go 
east to the barrel roos, 


In the barrel roca, get the match and the cosb, then 
crawl exit.. Drop the eatch by the trampoline, then head 
south to the rickety stairs and down to the landing. 60 
dom the slide into the tank. Get the rusty key, then give 
the cosb to the eereaid. 80 up the secret stairs she 
reveals, and you will be back on the landing. 


Bo east into the Windy Hall, and east again into the 
gaze, Now, carefully aake your way south, east, south, 
east, into the Mirror Roos. Wear the spectacles, and look 
in the airror, There's a hidden door! Open the door and 90 
inside, Here you find a valve handle. Drop the spectacles 
and get the handle, then go East back to the eirror roca. 


80 through the aaze to the roos with the knobs. drop 
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the key, then continue west and up until you ‘cone to the 
ledge. Get the trampoline, then go down the ladder to the 
pit. Drop the traspoline, then put handle and turn handle. 
You have now turned off the calliope in the eerry-go-round 
roos, 80 traspoline, and jump. Wheeee! You're back up. on 
the ledge. 


get the eatch, and return to the knob room. Drop the 
satch, get the key, and pull the blue knob. Now you're in 
the roca with the Fortune-telling machine. 80 east to the 
aerry-go-round root, 


Once in the eerry-go-round room, push the blue button 
to stop the ride. 80 merry, then go horse. Cliab the pole 
in the horse's back, which brings you to the top of the 
ride. Look up, and you will see a rope. Jusp! Now look, and 
you will see you are on a catwalk, Go east, and unlock the 
door. Drop the key, and look at the shelves. Brab the 
flashlight and the wrench, then head west, and cliab all 
the way down again, then return to the knob room. As you 
pass the fortune-telling machine, pick up the ‘out of 
order” sign. 


Pull the green knob, then go south to the shooting 
gallery. Drop the sign there, then return to the knob rooa. 
Get the aatch, then pull the yellow knob. This takes you to 
a seall room with strange ausic, 80 north into the saze, 
then go east, south, east, south, east, and you're in the 
Mirror Roos. Froa there, go south out of the Fun House. 


It's back to the parking lot. Open the grate. You will 
only be able to open one bolt, but you can slide the grate 
to aake rooe for yourself to go down. Drop the wrench and 
get the gua, Turn on the flashlight, then go down the 
aanhole, and east to the roos with the second grate. 


Close the door, and drop the ticket. Resove the heel 
from your shoe. A couple of things will fall out. One is a 
note expaining what this is all about, the other is a fuse. 
Drop the heel and the note, and get the fuse. 


Chew the gua again, then stick it to the fuse, and 
then to the grate, Light the fuse, and POP! the grate blows 
open. Get the ticket, then go through the hole, Now up 
through the shooting gallery and south to the hidden Jab. 
The secret plans are there! Grab then. 


COMGRATULATIONS!! You have successfully. coapleted your 
aission! 


epr tinted from 
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that 
many 
take 


February meeting. The problem is 
there are some overlaps - so you 
need to bring grandma along to 
notes. 
At 2:15 PM the following activities will 
take place; 


FROM THE DISK OF 


520ST SIG: Gary Nolan hosts another 
Dave Frazer 


information sharing session for you 
owners and soon-to-be owners of the 
Atari 520ST computer. (Or should we 
rename to the 1040/520ST SIG?) 


LEARNING PHONE WORKSHOP: Tom 


MILATARI LTD. 


is soon to be born. 


We have been in the process of incorp- 
oration for several months. The papers 


are now on their way to Madison for 
processing. 


Milatari, 
LTD., with be a non-profit educational 
corporation. As soon as we receive our 
approval from the state, we can proceed 
with filing for non-profit status with 
the Internal Revenue Service. 


After we have received the IRS approval 
we can begin acting like a non-profit 
organization. That is, will be able to 
mail at a lower postage rate, we can 
receive tax deductible donations and 
gifts and the paper work for the 
treasurer will increase 25 fold. 


Watch for our new name - but the game 
will remain the same! 


FEBRUARY MEETING PLANS 


Get your rollerskates ready folks, we 
have many activities planned for our 


soon to be known as MILATARI 


Terwilliger will present an on-line 
demonstration of Control Data's 
renamed PLATO system. The network 
provide” VIDEO-TEX products for 
eaucatiun. The available data bases 
serve children through adult learn- 
ing needs. 


BASIC CLASS: Steve Armstrong leads 
a new series of basic classes for 
the membership. The cost is $5.00 
per class. Be prepared to stretch 
your BASIC knowledge. 


At 3:30 we are pleased to have Ken 
Bergren join us. His presentation will 
on electronic mail services. 


Ken is the president of Electronic Mail 
Solutions, Inc. EMS represents both MCI 
Mail and Western Union's EasyLink 
electronic mail service in Wisconsin. 


At 4:15 we will hold our regular club 
business meeting. 


(Continued on page 6) 
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xxx CHRIS CRAWFORD *** ASSEMBLY LANGUAGE COURSE 
ANTIC PUBLISHING INC., COPYRIGHT 1985. REPRINTED BY PERMISSION. 
EXCLUSIVELY FOR USE OF WORLDWIDE USERS NETWORK 
LESSON SEVEN: INTCRRUPTS 


We now approach one of the most difficult topics in tte world of assembly 
interrupts. This is such a messy topic that very few high-level languages make any 
provision for interrupts. Moreover, interuppts are one of the best ways around crash 
your program hard. Programmers using interrupts must be very careful. 


The standard way to handle this problem is with a technique called polling. Your 
program runs out every now and then to check whether the high-priority situation has 
arisen. If it has, then the program responds to it. If not, it returns to its 
original work. 


The problem with polling arises from the choice of polling interval. If you choose 
a long (infrequent) polling interval, then you may not respond to a demand quickly 
enough. If you choose a short (frequent) polling interval, then you will respond 
quickly to the demand, but you will never have any time for your regular computations. 


You may think this type of situation is infrequent, but I can list quite a few 
situations where this is fairly common. Most 1/0 operations involve short bursts of 
computation at infrequent intervals, but they must be attended to on a tight schedule. 
For example, talking to a cassette deck involves very little real work from the CPU, 
but it must be done according to a precise schedule. 


Even a disk drive is very slow by the standards of a 6502. Or how about keyboard 
response? When the human operator presses a button, he wants to see response NOW, not 
two or three seconds from now. Yet he could press that button at any time. So should 
your program sit on its hands waiting for a keypress, or should it ignore the human 
operator? 


The solution to all of these problems is the interrupt. An interrupt is rather 
like a subroutine that can be called by a hardware action. There's a wire going into 
the 6502 called IRQ (Interrupt Request). That wire is normally quiet, But when 
something important happens, like a keypress, the computer's hardware puts a signal on 
that wire to interrupt the 6502. Here's what happens next: 


The 6502 is busy running a program, but when it gets the interrupt signal it first 
checks the 1-bit (Interrupt) in the processor status register. If the 1 bit is set, 
it decides to ignore the interrupt, but if it is clear, it proceeds to the next step. 
It saves the processor status register and the current value of the program counter 
onto the stack. 


Then it loads the program counter with the address stered at o special place in ROM 
it's either $FFFC or r AFFE. J can never giet it straight It thus jum. to the 
address specified in ROM. It expects to find an interrupt service routine there 
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presumably will deal with the keypress in the appropriate manner. 


This routine will probably start by pushing A, X. and Y into the stack to preserve 
them. When done, the routine will then pull them off the stack and execute an RTI 
instruction, which causes the 6502 to pull the processor status register off the 
stack, and then pull the program counter off and resume operating. 


The important thing about this rather complex sequence is that it allows the 6502 
to drop whatever it is doing, service the interrupt, and then return to its earlier 
functioning without skipping a beat. The overriding goal of all this is to be 
absolutely certain that, when the 6502 reeturns from the interrupt, it returns in 
EXACTLY the same state that it was in when the interrupt hit. Otherwise, all sorts of 
horrible, untraceable bugs would result. 


Imagine -- you're in the middle of some huge computation when an interrupt strikes. 
It subtly changes some very tiny parameter, just enough to insure that when the 
computation resumes, it will be slightly incorrect. When you try to find the bug, you 
discover that sometimes the code works perfectly and sometimes it fouls up, and you 
can't figure out why it should do that. Very bad business! 


Moral: interrupts must follow a very tight discipline if they are to be of any 
utility. 


= Now let's get into some of the technical gore involving interrupts. First, there 
are two interrupts on the 6502. They are called IRQ (Interrupt Request) and NMI (Non- 
Maskable Interrupt). The idea is that the IRQ cterppts are on of the best ways around 
crash your program hard. Programmers using interrupts must be very careful. 


The standard way to handle $ problem is with a technique called polling. Your 
program runs out every now and then to check whether the high-priority situation has 
arisen. If it has, then the program responds to it. If not, it returns to its 
original work. 


The problem with polling arises from the choice of polling interval. If you choose 
a long (infrequent) polling interval, puters don't allow that. 


The NMI and IRQ interrupts have separate interrupt vectors in ROM, so they can be 
treated differently. These vectors route the interrupts to the OS, but the OS is smart 
enough to route interrupt flow thorugh some RAM locations. This means that you can 
intercept these two interrupts by altering the contents of the RAM-vectors. (I won't 
list them here, there are a number of them for different situations. ) 


You must be careful, though, when altering such a RAM vector. What happens if an 
interrupt strikes after you have changed one byte of the address and before you have 
changed the other byte? The 6502 will fly off into never-never land and you have 
crashed. Sure, it's unlikely, but good programmers don't count on luck to make their 
programs work. You have to guarantee that the interrupt won't occur before you mess 
with the vector. Use SETVBV from the 08. 


The two primary applications of interrupts with the Atari computers are for VBIs 
(Vertical Blank Interrupts) and DLIs (Display List Interupts). These are very 
involved topics covered quite thoroughly in th book De Re Atari. VBIs are most often 
used for animation control, input handling, and other time-critical operations. For 
example, the entire player I/0 of my game Eastern Front (1941) is handled by VBIs. The 
scrolling, giving of orders, identifying units, and so forth is all done by VBIs. The 
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mainline routine meanwhile figures the artificial intelligence. 


DLIs are used to enhance the graphics on the screen. 5, MO 
and more character sets with proper use of DLIs. 


use out of players, more scrolling, 


You can get more colors, more 


Again, consult De Re Atari for a full treatment of this complex subject. 


Interrupts are extremely difficult to debug because they tend to crash the system 


when they fail. 
Timing problems, 
interrupts. 


What happens, for example, 


execution time that more interrupts arrive than you can service? 
what happens if an interrupt strikes here? 
You must assume that an interrupt will strike at the worst possible time, and 


you. You must always ask yourself, 
there? 


You must exercise the strictest discipline in writing interrupt code. 
seldom of concern in mainline programming, 


can become critical with 


if your interrupt service routine takes so much 


Bad things, I assure 
Or 


write your code to deal with that possibility. 


The most important discipline to follow in writing interrupt service routines 
this: keep your interrupt database separate from your mainline database. 
can freely write to variables used by the mainline, 


is 
If the ISR 
you will certainly have problems 


when the mainline attempts to work with variables whose values change in unpredictable 


ways. You must set up ironclad rules about when the ISR can mess with variables 
what it can do to them, 


by the mainline, 
that it has indeed altered them. 


Approach interrupts with extreme caution. 


used 
and how it notifies the mainline routines 
They are very powerful, but every 


programmer can tell you horror stories about debugging interrupt routines. 


DAVE'S DISK (Continued from page 3) 


At 4:45 there will be a special meeting 
of the ATR8000-CP/M SIG. We will discuss 
the status and future plans of this 
group. 


CALLING ALL OFFICER MATERIAL 


I will be selecting a nomination 
committee at the February board meeting. 
I would like anyone interested on being 
on the nominating committee, or better 
yet, anyone who would like to be a 
candidate to see me at the meeting. The 
elected positions are President, Vice 
President, Secretary and Treasurer. The 
report of the nominating committee will 
be presented at the April meeting and 
elections will be help in May. 


CALLING ALL BUDDING AUTHORS 
You write programs, you know they're 


good, but you don't know where to go 
from there. 


A communique received from DATASOFT asks 
for submissions. They want to see 
original graphic adventure games, action 
adventure games and action arcade style 
games full of color and animation. Also, 
home productivity programs with mass 
market appeal. Prefer programs written 
in machine language, but will consider 
outstanding submissions in BASIC. Pro- 
grams should be written for ATARI, APPLE 
II, COMMODORE 64, IBM PC, TANDY 1000 OR 
TANDY COLOR COMPUTER. They also want 
products for ATARI ST, MACINTOSH and 
amiga. Graphics is very important. 


Send your submissions to; 
DATASOFT 
Marketing Project Manager 
19808 Nordhoff Place 
Chatsworth, CA 91311 
(818) 886-5922 


DATASOFT promises you a prompt reply. 


Mi Ll bien 
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** Professional GEM ** 

by Tim Oren 
Topic: WINDOUS, part I 


Wotidwide™ 
Users 


ANTIC is proud to present the firat of Tim 
Oren’s bi-monthly columns exploring the GEM 
programming environment. These columns are 
aimed at professional ST developers, but we 
encourage everyone to join in and collect the 
columne for future reference. 


HELLO, WORLD! 
For those whom 1 have not met in person or 
electronically, an introduction is in order. 

I am a former member of the GEM 
programming team at Digital Research, Inc., 
where I designed and implemented the GEM 
Resource Construction Set and other parts of 
the GEM Programmer's Toolkit. I have since 
left DRI to become the user Interface 
á gner for Activenture, a startup company 
which is developing CD-ROM technology for use 
with the Atari ST and other systems. 

The purpose of Professional GEM is to 
paes along some of the information and tricks 
I have accumulated about GEM, and explore 
some of the user interface techniques which a 
powerful graphics processor auch as the ST 
makes poasible. 


GROUND RULES 

I am going to assume that you have both a 
working knowledge of the C programming 
language and a copy of the ST Programmer's 
Toolkit with documentation (available from 
Atari). If you lack either, don't panic. 
You can read the columna to get the flavor of 
programming the ST, and come back for a more 
serious visit later on. 

For now, I will be using code samples 
that will run with the Atari-supplied C 
compiler, aleo known as DR C-68K, or Alcyon 
E. I will be using the portability macros 
supplied with the Toolkit, so that the code 
will also be transferable to other GEM 
a> “ems. 

Both of these items are subject to 
change, depending on reader feedback and the 
avallability of better products. 

If you do not have a copy of the source 


to the DOODLE.C GEM example program, you 
should consider downloading a copy from 
SIG*ATARI (or get a copy from the MILATARI 
SIG library -ed ). Although it ia poorly 
documented, it shows real-life examples of 
many of the techniques I will discuss. 

Getting started with a windowed graphics 
ayatem seems to be like getting into an 
ice-cold swimming pool: it’s best done all at 
once. 

Anyone who has looked at "Inside 
Macintosh” has probably noticed that you have 
to have read most of it to underatand any of 
Lt: GEM isn't really much different. You 
have all the reference guides in your hand, 
but nothing to show how it all works 
together. 

I am hoping to help thia situation by 
leading a series of short tours through the 
GEM jungle. Each time ve 11 go out with a 
particular goal in mind and follow the path 
that leads there. We’ll look at the pitfalls 
and strange bugs that lurk for the unwary, 
and show off a few tricks to amaze the 
natives. The firat trip leaves immediately; 
our mission is to get a window onto the ST 
screen, with all of its parts properly 
initialized. 


VE DO VINDOUS 

One of the most important services which a 
graphics interface system provides for the 
user and programmer is window management. 

Vindows allow the user to perfora more 
than one activity on the same screen, to 
freely reallocate areas of the screen for 
each task, and even to pile the information 
up like pages of paper to make more room. 
The price for this increased freedom ia (as 
usual) paid by you, the programmer, who must 
Master a more complex method of interacting 
with the “outside world”. 

The windowing routines provided by ST 
GEM are the most comprehensive yet available 
in a low-cost microcomputer. Thia article is 
a guide to using these services in an 
effective manner. 


IN THE BEGINNING 
In GEM, creating a window and displaying it 
are two different functions. The creation 
function is called wind create, and its 
calling sequence la: 
handle = wind create(parta, xfull, yfull, 
wfull, hfull); 
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This function asks GEM to reserve space 
in its memory for a new window description, 
and to return a code or “handle” which you 
can use to refer to the window in the future. 
Valid window handles are positive integers; 
they are not memory pointers. 

GEM can run out of window handles. If 
it does so, the value returned is negative. 
Your code should always check for this 
situation and ask the program's user to close 
some windows and retry If possible. Handle 
zero ia special. It refers to the desktop“, 
which is predefined as light green (or gray) 
on the ST. Window zero ia always present and 
may be used, but never deleted, by the 
programmer. 

The xfull, yfull, wfull, and hfull 
parameters are integera which determine the 
maximum size of the window. Xfull and yfull 
define the upper left corner of the window, 
and wfull and hfull specify ita width and 


height. (Note that all of the window 
coordinates which we use are in pixel 
unite.) 

GEM saves these values so that the 


program can get them later when processing 
FULL requests. Usually the best maximum size 
for a window is the entire desktop area, 
excepting the menu bar. You can find this by 
asking wind get for the working area of the 
desktop (handle zero, remember): 

wind_get(0, WE_UXYUH, &xfull, 
awfull, &hfull); 

Note that UF_UXYUH, and all of the other 
mnemonics used in this article, are defined 
in the GEMDEFS.H file in the ST Toolkit. 

The parts parameter of wind create 
defines what features will be included in the 
window when it la drawn. It is a word of 
single bit flags which indicate the 


&yfull, 


presence/absence of each feature. To request 
multiple features, the flags are ”or-ed” 
together. The flags mnemonica and meanings 
are: 


NAME- A one character high title bar at the 
top of the window. 


INFO- A second character line below the 
NAME. 
MOVER- This letas the user move the window 


around by "dragging” in the NAME area. NAME 
also needs to be defined. 

CLOSER - A square box at the upper left. 
Clicking this control point asks that the 
window be removed from the screen. 

FULLER - A diamond at upper right. 


Clicking this control point requesta that th. 
window grow to its maximum size, or shrink 
back down if it is already big. 

SIZER - An arrow at bottom right. 
Dragging the SIZER lets the user choose a new 
size for the window. 

VSLIDE - defines a right-hand scroll box 
and bar for the window. By draggingthe scroll 
bar, the user requests that the window's 
“viewport” into the information be moved. 
Clicking on the gray box above the bar 
requests that the window be moved up one 
page. Clicking below the bar requests a 
down page movement. You have to define what 
constitutes a page or line in the context of 
your application. 

UPARROW - An arrow above the right scroll 
bar. Clicking here requesta that the window 
be moved up one “line”. Sliders and arrows 
almost alvaye appear together. 

DNARROU - An arrow below the right scroll 
bar. Requests that window be moved down a 
line. 

HSLIDE - These features are the horizontal 
equivalent of the RTARROU above. They appear 
at the bottom of the window. Arrows LFARR( 
usually indicate “character” sized movement 
left and right. Page“ sized movement has to 
be defined by each application. 


It is important to understand the 
correapondence between window features and 
event messages which are sent to the 


application by the GEM window manager. If a 
feature is not included in a window's 
creation, the user cannot perform the 
corresponding action, and your application 
will never receive the matching message type. 
For example, a window without a MOVER may not 
be dragged by the user, and your app will 


never get a UM_MOVED message for that 
window. 

Another important principle is that the 
application itself is responsible for 


implementing the user's window action request 
when a message la received. This gives the 
application a chance to accept, modify, or 
reject the user's request. 

As an example, if a UM_MOVED message is 
received, it indicates that the user has 
dragged the window. You might want to byte 
or word align the requested position befor 
proceeding to move the window. The wind_se 
calla used to perform the actual movements 
will be described in the next article. 


MM ML ban 


PAGE 9 


OPEN, SESAME! 

The vind open call is used to actually make 
the window appear on the screen. It animates 
a "zoom box” on the screen and then draws in 
the window's frame. The calling sequence 
is: 

wind open(handle, x, y, w, h); 
handle ia the one returned by wind create. 
Parameters x, y, w, and h define the initial 
location and size of the window. Note that 
these measurements INCLUDE all of the window 
frame parta which you have requested. To find 
out the size of the area inside the frame, 
you can use 

wind get(handle, UF_UXYUH, 
tinner_ y, &inner w, inner h); 

Whatever size you choose for the window 
display, it cannot be any larger than the 
full aize declared in wind create. 

Here is a good place to take note of a 
useful utility for calculating window sizes. 
If you know the "parts list” for a window, 
and its inner or outer size, you can find the 
other size with the wind cale call: 


&inner_x, 


wind calc(parte, kind, Input x, input y, 
out v, input_h, &output x, &output_y, 
- dtput_w, &output_h); 

Kind is set to zero if the input 


coordinates are the inner area, and you are 
calculating the outer size. Kind is one if 
the inputs are the outer size and you want 
the equivalent inner size. Parts are just 
the same as in wind create. 

There ig one common bug in using 
wind open. If the NAME feature is specified, 
then the window title must be initialized 
BEFORE opening the window: 

wind set (handle, UF_NAME, 
0); 


ADDR(title), 0, 


If you don’t do this, you may get 
gibberish in the NAME area or the system may 
crash. Likewise, if you have specified the 
INFO feature, you must make a wind set call 
for WF_INFO before opening the window. 

Note that ADDR() specifies the 32-bit 
address of title. This expression la 
portable to other (Intel-based) GEM systens. 
If you don't care about portability, then 
áatitle[0], or just title alone will work fine 
on the ST. 


CLEANING UP. 
bnen you are done with a window, it should be 
closed and deleted. The call 


wind close(handle); takes the window off the 


screen, redraws the desktop underneath it, 
and animates a "zoom down” box. It doesn't 
delete the window’s definition, so you can 
reopen it later. 

Deleting the window removes ite 
definition from the system, and makes that 
handle available for reuse. Always close 
windows before deleting, or you may leave a 
"dead” picture on the screen. Also be sure 
to delete all of your windows before ending 
the program, or your app may eat“ window 
handles. The syntax for deleting a window 
is: 

wind_delete(handle); 


THOSE FAT SLIDERS. 

One of ST GEM's unique features is the 
proportional slider bar. Unlike other 
windowing systems, this type of bar gives 
visual feedback on the fraction of a document 
which is being viewed, as well as the 
position within the document. The catch, of 
course, ia that you have two variables to 
maintain for each scroll bar: size and 
position. 

Both bar size and position range from 1 
to 1000. A bar size of 1000 fills the slide 
box, and a value of one gets the minimum bar 
size. To compute the proper size, you can usé 
the formula: 

size = 
total_doc) 

Seen doc and total doc are the visible 
and total size of the document respectively, 
in whatever units are appropriate. As an 
example, if your window could show 20 lines 
of a 100 line text file, you should set a 
slider size of 200. Since the window might 
be bigger than the total document at some 
points, you need the maximum function. If 
the document size is zero, force the slider 
size to 1000. (Note: You will probably need 
to do the computation above with 32-bit 
arithmetic to avoid overflow problems.) 

Once you have computed the size, use the 


min(1000, 1000 * seen doc / 


wind set function to configure the scroll 
bar: 

wind set (handle, WF_VSLSIZE, size, 0, 0, 
0); 


This call sets the vertical (right hand) 
scroll bar. Use UF_HSLSIZE for the 
horizontal scroller. All of these examples 
are done for the vertical dimension, but the 
principles are identical in the other 
direction. 
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Bar positioning is a little tougher. 
The most confusing aspect is that the 1-1000 
range does not set an absolute position of 
the bar within the scroll box. Instead, it 
positions the TOP of the bar within ite 
possible range of variation. 

Let’s look at our text file example 
again to make this clearer. If there 
arealways 20 lines of a 100 line file 
visible, then the top of the window must be 
always be somewhere between line 1 and line 
81. Thia 80 line range ia the actual freedom 
of movement of the window. So, if the window 
were actually positioned with its top at line 
61, it would be at the three-quarter position 
within the range, and we should set a acroll 
bar position of 750. The actual formula fer 
computing the position is: 

pos = 1000 * (top wind - top doc) / 
(total_doc - seen doc) 

Top wind and top doc are the top line in 
the current window and the whole document, 
respectively. Obviously, if seen doc is 
greater or equal to total doc, you need to 
force a zero value for pos. This calculation 
may seen rather convoluted the first time 
through, but is easy once you have done it. 
When you have computed the position, wind set 
configures the scroll bar: 

wind set (handle, UF_VSLIDE, pos, 0, 0, 0); 
UF_HSLIDE ia the equivalent for horizontal 
scrolling. 

It is a good practice to avoid setting 
the slider size or position if they are 
already at the value which you need. Thia 
avoids an annoying redraw flash on the screen 
when dit is not necessary. You can check on 
the current value of a slider parameter with 
wind_get: 

wind get (handle, 
&foo, foo, foo); 

Foo is a dummy variable which needs to 
be there, but is not used. Substitute 
UF_VSLIDE with whatever parameter you are 
checking. 

One philosophical note on the use of 
sliders: It is probably best to avoid the 
use of both sliders at once unless it is 
clearly appropriate to the type of data which 
is being viewed. 

Since Write and Paint programs make use 
of the sheet-of-paper metaphor, moving the 
window around in both dimensions is 

reasonable. However, if the data is more 
randomly organized, such as a tableau of 


WF_VSLIDE, acurr_value, 


icons, then it is probably better to iy 
scroll in the vertical dimension and 
"reshuffle” if the window’awidth is changed. 
Then the user only needs to manipulate one 
control to find information which la 
off-acreen. Anyone who has had trouble 
finding a file or folder within a Desktop 
window will recognize this problem. 


COMING UP NEXT 

In my next column in Antic Online, we'll 
conclude the tour of the ST’s windowing 
system. 1˙11 discuss the correct way to 
redraw a window's contents, and how to handle 
the various messages which an application 
receives from the window manager. Finally, 
we’ll look at a way to redesign the desktop 
background to your own specifications. 


The Man From A.S.C.I.I. 
REPORT #0985 
E.Z. HINTZ REPORTING... 


SEND ALL QUESTIONS TO: 
MAN FROM A.S.C.I.I. 
C/O ROBERT WROBEL 

606 CARLTON 

TOLEDO, OHIO 43609 


—Toleqdo 


ADVENTURE: THE INSTITUTE 


QUESTION: I KNOW THAT I NEED A 
PLANT TO STAY IN THE STATUE’S 
HEAD. MY QUESTION IS WERE IS THE 
PLANT, I CANNOT FIND IT ? 


HINT: FOR THIS ONE I HAD TO GO 
TO A HIGHER SOURCE- THE HINT 
LORD. WE COMBINED OUR WISDOM AND 
KNOWLEDGE TO COME UP WITH A one 
word HINT: 

T AIRS Y 


ADVENTURE: THE RETURN OF 
HERACLES 


QUESTION: IS HERACLES TO BE 
FOUND? 


HINT: THE STRONGEST MAN WILL 
OBEY YOUR COMMANDS IF YOU START 
WITH THE CORRECT CHARACTER AND 

VIST THE RIGHT ORACLE. STUDY YOUR 
MYTHOLOGY ! 
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expressed in this publication are those 
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membership fee is £15 for individuals or 
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Vendors wishing to display and/or sell 
items at MILATARI meetings must make 
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president. Rates are $10 per meeting or 
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ALL material in this newsletter not 
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reprinted in any form, provided that 
MILATARI and the author are given credit. 


Other computer user groups may obtain 
copies of this newsletter on an exchange 
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advertising copy from anyone supplying 
goods and services of interest to our 
membership. 


Current paid members of  MILATARI may 


place classified ads in the newsletter at 
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NEW & RECENT SOFTWARE RELEASES New. z 
FOR YOUR ATARI HOME COMPUTER 3) 


Alternate Reality (Datasoft) 
Atari Writer Plus (Atari) 


Aztec (Datamost) Nam (SST) 

Borrowed Time (ST)(Activision) Panzer Grenadier (SSI) 

D. Z. G. A. S. (ST)(Batteries Included) Rubber Stamp (Xlent) 

Fahrenheit 151 (ST)(Telarium) - Spanish (American Educational) 
Forbidden Quest (ST) (Pryority) Spellbreaker (Infocom) 

Hacker (ST)(Activision) Spy vs. Spy Vol. II (First Star) 
Kampfgruppe Scenery Disk 1 (SSI) Sundog/Frozen Legacy (ST)(FTL) 
King's Quest II (ST) (Sierra) VIP Professional (ST) (VIP) 
Masters of Time (Cosmi) Wishbringer (ST)(Infocom) 


These are only a few of the reasons your software store should be... 


COMPUTER SOFTWARE CENTER 
9805 W. Oklahoma Ave., Milwaukee 


(Two biocks East of interstate 894) 


Tues.-Fri. 12-8, Sat. 12-5 (414) 543-5123 


— — AA IRIS '] — — 


THERE'S MORE IN STORE FOR YOU AT 98TH & OKLAHOMA 


